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Method and Apparatus to Support VirtuaHzation with Code Patches 
Fi Pld of the Invention 

Thepre sent disclosure reiates generally to the field of data processing, and 

more particularly to methods and related apparatus for supporting vrtual 
machines in a data processing system. 

Background 

As recognized in Revision 2.0 of the Intel® Virilization Technology 
Specification for the Intel® ftanium® Architecture (VT-i). dated April 2005 
(hereinafter "the VT-I Specification"), conventional operating system (OS) des.gns 
typically assume the OS has complete and direct control of hardware and system 
resources. The OS implements the policies to manage these resources to a low 
multiple user-level applications to be run. The goal of vir.uallza.ion is hyp.ca.ly to 
a„ow multiple instances of OSs to be run on a system. The OSs can be same or 
different versions, and can come from different OS vendors. 

In a typical virtualized environment, there will be a piece of system software 
responsible for vitalizing the hardware and system resources to allow mulfiple 
instances of the OSs to be run. The sofiware component ma. provides such 
functionality is referred to herein as .he vidua, machine monitor (VMM). The VMM 
is typically a piece of host software that is aware of the hardware architecture. 

For each instance of guest OS, the VMM creates and presents a virtual 
machine (VM) to the guesi OS. From .he perspective of a guest OS, the VM 
includes all the hardware and system resources (e.g., processors, memory, d,sk, 
network devices, etc.) expected by the gues. OS. From .he VMM perspective, 
these hardware and system resources are "virtualized." 

For example, a VMM may create a VM that presents two logical processors 
to one guest OS, and a VM that presents one logical processor to another gues. 
OS The actual underlying hardware, however, may include less than, equal to. or 
0 greater than three physica, processors. The logical processors presented to a 
gues. OS are called virtualized processors. Likewise, VMs may include v,rtual,zed 
storage, peripherals, etc. 
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The VT-i Specification and a corresponding specification dated April 2005 
for the IA-32 Intel® architecture (the VT-x Specification) may be obtained from 
hjj^/www iq ^ 1 r.nm/technolon>^r nmpntino/vptech/. 

Virtualized environments include fully virtualized environments, as well as 
paravirtualized environments. In a fully virtualized environment, each guest OS 
operates as if its underlying VM is simply an independent physical processing 
system that the guest OS supports. Accordingly, the guest OS may expect or 
require the VM to behave according to the architecture specification for the 
supported physical processing system. By contrast, in paravirtualization, the 
0 guest OS helps the VMM to provide a virtualized environment. Accordingly, the 
guest OS may be characterized as virilization aware. For instance, a 
paravirtualized guest OS may be able to operate only in conjunction with a 
. particular VMM, while a guest OS for a fully virtualized environment may operate 
on two or more different kinds of VMMs. 
5 A VMM may use emulation to perform certain operations on behalf of a 

guest OS. For instance, the guest OS may include an instruction to access a 
. register. However, since the register will reside in a virtualized processor, the 
VMM may need to emulate the access for the guest OS. 

One approach for supporting virilization involves hardware assistance or 
20 acceleration for emulating guest operations. However, certain types of processors 
may lack the control logic needed to provide hardware assistance for virtual.zat.cn, 
and other types may provide hardware assistance to emulate some guest 
operations but not all guest operations or instructions that need to be emulated. 
When hardware assistance is not available or not sufficient to handle all 
25 emulation requirements, other approaches may be used, including emulation 

techniques that use code patches which cause interrupts, exceptions, faults, and 
the like (referenced generally hereinafter as faults). For example, to facilitate 
emulation of certain operations, a VMM may apply patches to insert new code .nto 
code being executed by a VM. Specifically, the patches may augment or replace 
30 existing code. For instance, the VMM may replace old code with new code while 
keeping with original code size, so that it is not necessary to relocate the whole 
binary. Each patch, when executed, may cause the processing system to 
generate a fault. 



For purposes of this disclosure, the term "emulation patch" refers to a patch 
mat is applied to code of a guest VM, to facilitate the emulation of operates for 
the guest VM. Emulation patches may be applied statically or dynamically. To 
handle a fault triggered by an emulation patch, a conventional processing system 
5 saves and eventually restores the contextual data that defines or constitutes the 
system state for the guest VM. That contextual data may be called the trap frame. 

An emulation patch may include or consist of a pseudo instruction. For 
purposes of this disclosure, a pseudo instruction is an instruction that is undefined 
or that includes an invalid argument or value. Consequently, when a pseudo 
10 instruction from an emulation patch (i.e., a patched pseudo instruction) ,s 

executed, it will trigger a fault (e.g., an illegal operation fault). Reserved fields or 
other special instructions may be used as pseudo instructions. 

According to conventional approaches for supporting virilization, each of 
the emulation patches, when executed, may cause the processing system to save 
15 and restore the trap frame. It may be necessary to save the trap frame because 
some or all of the software used to handle emulation of the guest instruction may 
have been written in a high level language, such as C. Unfortunately, saving and 
restoring the trap frame may take many hundreds of instruction cycles. 

In addition, as described below, an exception handler in the VMM may 
20 perform a complex series of operations to determine which guest instruct,™ 

corresponds to the pseudo instruction that caused the fault, and to then emulate 
that guest instruction. Consequently, conventional emulation patches may have a 
significant impact on performance. 

25 R r i»f rtesr.rj pfi"" 01 The Drawing? 

Features and advantages of the present invention will become apparent 
" from the appended claims, the following detailed description of one or more 
example embodiments, and the corresponding figures, in which: 

Figure 1 is a block diagram depicting a suitable data processing 
30 environment in which certain aspects of an example embodiment of the present 
invention may be implemented; 

Figure 2 is a block diagram depicting the example VMM of Figure 1 in 

greater detail; and 
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Figure 3 is a flowchart depicting various aspects of a process to support 
virilization with code patches according to ah example embodiment of the 
present invention. 
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In a conventional virilization environment, when an emulation patch is 
executed it may be necessary to perform complex operations to determine wh.ch 
guest instruction is to be emulated. For instance, the emulation pat* may use a 
pseudo instruction that provides some information about the orig.nal guest 
instruction, but that pseudo instruction may not describe all necessary 
characteristics of the guest instruction. Consequently, the VMM may need to 
retrieve the original guest instruction to determine additional characteristics of that 
instruction, such as the source register (if any), the target register (if any), the 

branch register (if any), etc. 

Furthermore, the executing guest may only have an instruction s,de 
translation lookaside buffer (TLB), and the VMM may be unable to directly retneve 
code from data side memory. The VMM may therefore need to internally track the 
guest's TLB to be able to get the physical address for the guest instruction to be 
emulated The VMM may then need to retrieve that instruction in physical mode, 
rather than virtual mode, or insert a new data side TLB entry. For example, a 
VMM may use the following general approach to determine characterises for the 

guest instruction to be emulated: 

1 . Get the guest instruction pointer (guestJP) from an interrupt instructs 
pointer (IIP) of a control register (CR). 

2. Try to find the translation in the guest instruction side (I side) TLB that 
cover the address guestJP. 

3 insert a new entry in the data side (D side) TLB, based on the instructs 
from the I side TLB found in step #2. The new entry may match the old 
entry precisely, or the new entry may include minor changes. For instance, 

the I side entry may have an "execute only" attribute, but the D side entry 
may be given a "readable" attribute for the VMM ring (e.g. , ring 0). 

4 Read the instruction: ins= *(guest_IP). 

4 



5 Remove the translation of step #3. 
in addition or alternatively, as indicated above, the VMM may transition the 
processing system from virtual mode to physical mode to retrieve the instruction. 
Furthermore, after retrieving the guest instruction to be emulated, the VMM may 
consume substantial processing resources determining how to emulate that 
instruction. 

To facilitate code development and maintenance, or for other reasons, the 
routine or routines for determining how to emulate guest instructions may have 
been written in a high .eve. .anguage, such as C. The nature of those routine may 
make it necessary for the VMM to save the trap frame before calling those 
routines, and to restore the trap frame after those routines have executed. 

in a virilized environment, the above approach may be pract.cal to 
emulate complicated instructions, such as •■return from interruption" (rfi) for 
example However, for many virilization events, the techniques descnbed 
below provide a more efficient way to support emulation of guest operates or 
instructions. 

Figure 1 is a block diagram depicting a suitable data processing 
environment 1 2 in which certain aspects of an example embodiment of the 
present invention may be implemented. Data processing environment 12 .ncludes 
a processing system 20 that includes various hardware components 80 and 
software components 82. The hardware components may include, for example, at 
,east one processor or central processing unit (CPU) 22 communicative.y coupled 
to various other components via one or more system buses 24 or other 
communication pathways or mediums. 

As used herein, the terms "processing system" and "data process.ng 
system" are intended to broadly encompass a single machine, or a system of 
communicatively coupled machines or devices operating together. Example 
processing systems include, without limitation, distributed computing systems, 
supercomputers, high-performance computing systems, computing clusters, 
mainframe computers, mini-computers, client-server systems, personal computers 
(PCs) workstations, servers, portable computers, laptop computers, tablet 
computers, personal digital assistants (PDAs), telephones, handheld dev.ces, 



10 



15 



20 



25 



entertainment devices such as audio and/or video devices, and other devices for 
processing or transmitting information. 

Processing system 20 may be controlled, at least in part, by input from 
conventional input devices, such as a keyboard, a pointing device such as a 
mouse etc. Processing system 20 may also respond to directives received from 
other processing systems or other input sources or signals. Processing system 
20 may utilize one or more connections to one or more remote data process.ng 
systems 70, for example through a network interface controller (NIC) 32, a modem, 
or other communication ports or couplings. Processing systems may be 
interconnected by way of a physical and/or logical network 72, such as a local 
area network (LAN), a wide area network (WAN), an intranet, the Internet, etc. 
Communications involving network 72 may utilize various wired and/or w.re.ess 
short range or long range carriers and protocols, including radio frequency (RF), 
satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 
802 11 802 16 802.20, Bluetooth, optical, infrared, cable, laser, etc. 

Within processing system 20, processor 22 may be communicatively 
ooupled to one or more volatile or non-volatile data storage devices, such as 
random access memory (RAM) 26, flash memory 27, mass storage dev.ces 28 
such as integrated drive electronics (IDE) or smal. computer system .nterface 
(SCSI) hard drives, and/or other devices or media, such as floppy disks, optical 
storage tapes, read-only memory (ROM), memory sticks, compact flash (CF) 
cards digital video disks, bio.ogica. storage, etc. For purposes of this disclosure, 
the term "ROM" may be used in genera, to refer to non-volatile memory dev.ces 
such as erasable programmable ROM (EPROM), electrically erasable 
programmable ROM (EEPROM), flash ROM, flash memory, etc. Processor 22 
may also be communicatively coupled to additional components, such as v,deo 
controllers SCSI controllers, network controllers, universal serial bus (USB) 
controllers, input/output (I/O) ports 36, input devices such as a keyboard, a mouse, 
a camera etc. Processing system 20 may also include one or more br.dges or 
) hubs 34 such as a memory controller hub, an I/O controller hub. a penphera. 
component interconnect (PCI) root bridge, etc., for communicatively coupl.ng 
system components. As used herein, the term "bus" includes pathways that may 
be shared by more than two devices, as well as point-to-point pathways. 
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Some components, suoh as NIC 32. for example, may be implemented as 
adap »er cards with interfaces (e.g., a PC, connector) for communicating^ a bus. 
Aiternatively, NIC 32 and otber devices may be implemented as embedded 
controllers, using components such as programmable or non-programmab e , oglc 
devices or arrays, application-speciftc integrated circuits (ASICs), embedded 
computers, smart cards, and the like. 

The invention is described herein with reference to or in conjunct^ w,th 
data such as instructions, functions, procedures, data structures, applicat.on 
programs, configuration settings, etc. When the data is accessed by a mach.ne, 
L machine may respond by performing tasks, defining abstract data typesor 
,ow-leve, hardware contexts, andfor performing other operations, as desc „b ed n 
gre a.er detail below. The data may be stored in volatile and/or non-vola„le data 
Lrage For purposes of this disclosure, the term "program" is used in general to 
cover a broad range of software constructs, including applications, routmes, 
modules, drivers, subprograms, processes, and other types of software 

^Tor instance, data storage device 2S and/or RAM 26 may include various 
sets of instructions which, when executed, perform various operations. Such sets 
of instructions may be referred to in general as software. 

As illustrated in Figure 1 , in the example embodiment, the programs or 
software components 82 may include a. VMM 40. As described in greater detail 
below with regard to Figure 2, VMM 40 may include various programs and data 
structures for patching code for VMS, and for handling patched VM code 

,. illustrated in Figure 1 , VMM 40 may create VMs such as VM 60 and VM 
62 Different instances of guest OSs, such as guest OS 50 and gues, OS 52, may 
execute in those VMs. Also, various applications 64 may execute on top of each 
gues , OS The data associated with VMM 40 and VMS 60 and 62 may be stored 
in any suitable storage device or devices.. For instance, much or a„ of .ha, data 
may reside in RAM 26. However, portions of the data (e.g., state data, control 
> iogic, etc.) may reside in registers, cache, or any other suitable location ,n 
processor 22. 

Figure 2 is a block diagram depicting VMM 40 in greater detail. As 
iUustrated, in the example embodiment, VMM 40 includes a patch manager 110 



and an emulation manager 120. As described in greater detail below, when the 
VMS execute programs, patch manager 110 dynamically inserts patches rnto 
those guest programs to support virilization. Alternatively, VMM 40 or a 
different software module may insert the patches statically, in anticipate of 
execution of the guest programs. The inserted patches may include break 
instructions or other instructions that cause execution to shift from the guest 
program to another program, such as VMM 40. For purposes of this disclosure, 
such instructions may be referred to as emulation triggers. The inserted patches 
may replace or augment certain instructions in the guest programs. The inserted 
patches may also be referred to as binary patches. 

As described below, emulation manager 1 20 provides for executron of 
programs to emulate the guest instructions that have been patched by patch 
manager 110. 

Patch manager 1 1 0 may determine which instructions to patch based on a 
collection of information that (a) lists the guest instructions to be patched and (b) 
identifies code templates that may be used to generate instructions or procedures 
for emulating those guest instructions. That collection of information may be 
structured as one or more tables, or as any other suitable data structure(s). In the 
example embodiment, such a collection of information is depicted ,n F.gure 2 as 

code template map 112. 

- As indicated above, code template map 1 12 may include a predetermined 
list of instructions to be patched. A small set of example instruction entries is 
depicted as instructions 1 30 in Figure 2. Typically, the list will include privileged 
instructions and other instructions that VMM 40 must emulate for guest OSs, due 
to the vitalized nature of the environment within which the guest OSs operate. 
For example, the list of instructions to patch may include, without limitation, 
instructions such as the following: 

. instructions to copy data from a PSR to a register that does not reside in a 

register bank (e.g., MOV r14=PSR); 
. instructions to copy data from a PSR to a register that resides in a register 
bank (e.g.. MOV r16=PSR); 
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. instructions to oopy data from an interval time counter (itc) 

register (ar) to a register that does not reside in a register bank (e.g. MOV 
r12=ar.itc); 

. instructions to copy, data from an interval time counter (itc) appl.cat.on 
5 register (ar) to a register that resides in a register bank (e.g., MOV 

r18=ar.itc); 

. instructions to set the system mask (ssm) or reset the system mask (rsm) 
for the interrupt collection (IC) or alignment checking (AC) bits of the PSR; 
. instructions to set or reset the system mask for the interrupt enable b,t of 

10 the PSR (PSR.i); 

. instructions to copy data from the task priority register (TPR); 

. instructions to copy data into the TPR; 

. . instructions to copy data from the interrupt control register (ICR); 

. instructions to copy data into the ICR; 

15 . instructions to copy data from a CPU identification (CPU.D) register; 

. instructions to switch register banks (bsw); 

• cover instructions; 

. translation hashed entry address (THASH) or translation hashed entry tag 

(TTAG) instructions; 
20 • instructions to copy data from a region register (RR); 

• instructions to copy data into an RR; 

. instructions to copy data from an interval timer match (tTM) register or a 

default control register (DCR); 
. instructions to copy data into an ITM register or a DCR; 
25 in various embodiments, various subsets or supersets of these instructions may 
be included in the predetermined list of instructions to be patched. Other 
embodiments also may not include the above instructions, but may include one or 
m ore other instructions, whether similar or not to the inductions listed above. 
The number of different guest code instructions, to be patched may be vaned for 
30 any particular implementation, as may the number of different code templates to 
be used, depending on factors such as how much performance improvement ,s 
desired, and how much time and manpowers available for creating code 
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templates, in one embodiment, emulation patches are no. applied based merely 
on the type of guest instruction, bu, based on a predetermined lis. of specific 
instructions to be patched. In addition, in one or more embodiments, the VMM 
ma y sometimes decide not to patch an instruction, even though the instructor, 
appears on the lis, of patchabie instructions. For instance, the lis, of patchabte 
instructions may include a b-unit instruction, bu, when ,he VMM encounters M b- 
uni, instruction, the VMM may determine, based on any suitable operafing 
parameters o, ,he processing system, no, to patch the instruction, bu, instead to 
le, it fell back to a more or less conventional gues, instruction emulation routine. 

Code template map 1 1 2 may also identify or provide various reference 
code templates 1 32. As described in greater detait below, in the example 
embodiment, each code template 132 may provide an outline containing example 
instructions or instruction templates to be used as the basis for the actual 
emulation instructions or routines to be executed in place of the guest instructs 
being emulated. 

VMM 40 may also include one or more programs for building emulat.on 
routines. In Figure 2, the program or programs for generating emulation routines 
are depicted in general as customization program 114. To generate an emulatron 
routine customization program 1 14 may determine which o, ,he reference code 
templates 132 corresponds to the instruction to be emulated. Customized 
program 1 14 may then modify or "fix up" tha, template as necessary to emulate 
the particular operations specified in the instruction to be emulated. Accordingly, 
,ne customization program(s) may be referred to in general as fix-up log* For 
instance, when generating an emulation routine, customization program 1 14 may 
customize a reference cede template as necessary, based on characterises of 
the instructions to be emulated, such as ,he particular source and large, reg.sters 
named in tha, instruction, for example. VMM 40 may store the emulation reufines 
that it generates using any suitable data structure(s). Figure 2 illustrates venous 
emulation routines, such as Routine A and Routine B, for example, stored ,n an 

30 emulation routine database 116. 

An instruction typically includes a mnemonic (e.g., 'insert translate cache 
(ITCH and one or more operands (e.g.. vr). To emulate guest instructions, a 
VMM may consider all instructions with ,he same mnemonic to be the same ,y P e 
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of instruction. For instance, all gues, instructions that use the mnemonic for TTC 
may be considered to have the same type. For ail instructions that have the same 
type the VMM may use the same patch. 

' However, VMM 40 may consider the mnemonic and one or more operands 
when classifying instructions by type. For example, as indicated above, i two 
instructions use the same mnemonic but different types of registers (e.g., banked 
versus non-banked), VMM 40 may consider those two instructions to be efferent 

types of instructions. 

In some embodiments, VMM 40 may consider additional attributes of a 
guest instruction when determining how to patch that instruction. For instance, 
VMM 40 may apply different emulation patches, depending on the slot from wh.ch 
each instruct executes. For example, a guest instruction of 'rsm PSR.i" in slot 
0 may get one emulation patch, while that same instruction in slot 1 may get a 
different emulation patch. Different emulation patches may be needed so they 
oan set the correct return slot in PSR.ri, for example. Similarly, if a VM uses (a) 
one instruction that includes the "moV mnemonic together with a cerfam 
destination register and (b) another instruction that includes the same mnemonic 
but a different destination register, VMM 40 may insert a different patch for each 
of those two different instructions. Thus, VMM 40 may apply different patches for 
different instructions, based on differences in the mnemonics, any one or more of 
, he operands (e.g., a source register, a destination register, or an immedrate 
value) the slots associated with the instructions in the guest bundles, or any other 
suitable attribute or combination of attributes of the instructions. In particular, 
instructions may be considered to be different instructions if any attributes are not 
me same However, if two instructions only differ in their location within the guest 
program, the same patch may be used to patch both of those instructions. 

in the example embodiment, processing system 20 uses an architecture ,n 
which instructions are grouped into bundles before execution. Table 1 below 
illustrates two example bundles, with each bundle including three guest 
instructions (in slots 0-2) and a field to indicate the type of template used by the 
bundle The template may specify the type of unit (e.g., I, M. B, F, or X) to be 
found in each slot. For instance, a bundle with an W template may have an 
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M-unit instruction, an M-unit instruction, and an l-unit instruction in slots 0-2, 
respectively. 



SlotO 



Instruction 1 



Instruction 4 



Slot! 



mov r14=PSR 



mov M5=PSR 



Slot2 



Instruction 3 



Instruction 6 



Template 



MM I 



MM I 



Table 1: Example Instruction Bundle, Before Patch 
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In Table 1 , the first bundle includes an instruction to move the value of the 
PSR to application register r14, and the second bundle includes a similar 
instruction but with the destination register of r15. VMM 40 may patch each of 
those "mov_from_PSR" instructions with a different patch. 

For instance, as illustrated in the first row of Table 2 below, VMM 40 may 
replace the guest instruction having the destination register of r14 with a break 
instruction having a particular immediate value (e.g., BASEJD+0, where 
BASEJD is any suitable base value). As shown in the second row, VMM 40 may 
replace the guest instruction having the destination register of r1 5 with a break 
instruction having a different immediate value (e.g., BASEJD+1). The patches 
shown in slot 1 may be considered emulation triggers. 




Instruction 1 



break.m BASEJD+0 



break.m BASEJD+1 



Instruction 3 



Instruction 6 



MM I 



Table 2: Example Instruction Bundle, After Patch 
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When different patches are used for each different instruction, emulation 
manager 120 VMM may not need to retrieve the corresponding guest instruction, 
and may determine how to emulate that guest instruction in a very simple manner. 
For instance, emulation manager 120 may determine which emulation routine is 
needed by simply using the immediate value from the patch as an index into 
emulation routine map 122. Emulation manager 120 may obtain the patch's 
immediate value from an interrupt immediate control register (cr.iim), for example. 
Alternatively, a patch may include an address, a label, or any other suitable type 
of data to be used for locating the corresponding emulation routine. For example, 
an emulation patch may use a branch instruction that identifies the entrance of the 
desired emulation routine (e.g., br patch_function_0). In one embodiment, 
emulation manager 120 retrieves the immediate value from cr.iim for a 
break.m/i/f/x instruction, and emulation manager 120 uses a combination of the 
guestJP address (cr.iip) and the region identifier (RID) to locate the emulation 
routine for a break.b instruction. 

Consequently, the code in emulation manager 120 for determining how to 
emulate patched guest instructions need not be overly complex, and may be 
written in a low level programming language such as assembly. Therefore, VMM 
40 may use patches that do not require heavyweight context switches. 

In one embodiment, there is one emulation routine for each virtual 
processor (VP). Alternatively, there may be one emulation routine per VMM. In 
the latter case, the emulation routine may obtain additional information to identify 
the current VP. 

In addition, in one embodiment, VMM 40 uses the break instruction in some 
or all emulation patches, but with different immediate values used for different 
guest instructions. As depicted in emulation routine map 122, each immediate 
value may correspond to a particular one of the emulation routines in database 
116. The immediate value for each emulation routine may be assigned by 
customization program 114 when customization program 114 creates that 
emulation routine. 

Also, since the break instruction can be executed in I, M, B, F, or X units, 
patch manager 1 1 0 may insert a patch into a bundle with any template without 
changing the template of that bundle. Also, emulation manager 120 may obtain 
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the immediate value from the cr.iim register or use any other suitable approach 
as described above. The immediate values may thus distinguish each d.fferent 
emulation routine. Also, VMM 40 may reserve a predetermined range of 

qaqf in tn BASE ID + RESERVED NUM) for use 
immediate values (e.g., from BASEJD to BAbtju 

in patches. 

Furthermore, customization program 1 14 may use a low level language 
such as assembly for some or all of the emulation routines. For example, when 
generating an emulation routine to emulate a guest instructs of 
■mov from PSfV oustomization program 1 14 may write that emulation routtne ,n 
assembly. Some or all emulation routines also may use only scratoh bank 0 
registers for internal variables. 

in Figure 2, emulation routine map 1 22 assooiates Routine A with the 
immediate value BASEJD+0. Customization program 1 14 may have orea.ed 
Routine A to emulate a guest mov_from_PSR instruction involving a non-banked 
target register. The following lines provide one example of a pseudo code 
representation of Routine A, which may be executed by VMM 40 to emulate a 
guest mov_from_PSR instruction in guest slot 1 involving a non-banked target 
register: 

20 mov_from_psr_nbr: 

/* 

* bO and pr are destroyed before entering this function 
*/ 

vpsr = vpd.vpsr 

vpsr = (vpsr & ~UM_BITS) | (machine PSR & UM_BITS) 

// depend on virilization policy. UMJ3ITS: User mask b.ts 

vpsr.ri=1 // Slotl is patched 
R15 = vpsr //emulation result of "mov r15=psr" 
machine PSR.ri =2 // point to next slot 

if ( vpsr.ic ) cr.iipa = cr.iip // update iipa, depend on virilization policy 
restore bO and PR 
rfi 
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When guest execution hits an emulation patch, emulation manager 120 takes 
control and executes the above mov_from_psr_nbr program if the immediate 
value in cr.iim matches the index for that program in emulation routine map 122 
(or, if cr.iim=0, if a combination of the guestJP and RID matches the index for that 
program). In other embodiments, such as an embodiment using a different VMM, 
a different routine may be used to emulate the same guest instruction or a similar 
guest instruction. 

The following lines provide a pseudo code representation of some of the 
logic in emulation manager 120: 

Breakjnstruction: 

save bO and PR 

if ( cr.iim within reserved break immediate ) { 

goto patching_function_entry[cr.iim - BASEJD] 

// mov_from_psr_nbr() in this example; see pseudo code 



above 

} 

else if ( cr.iim == 0 && (cr.iip & rid match entry in database of emulation 
routines) ) { 

20 Goto patching_function found. 

} 

else { 

restore bO and PR 

execute normal break interruption handler 

25 } 

In one embodiment, break instructions are used as the emulation triggers. 
However, in other embodiments, other types of instructions may be used to cause 
execution to shift from the guest program to another program, such as VMM 40. 
' 30 In various embodiments, for emulation triggers, patch manager 1 1 0 may use 
instructions such as branch, jump, goto, break, call, and other instructions 
designed to cause interrupts, faults, exceptions, traps, or other transfers of control 
from one program to another. For instance, in one embodiment, instructions of 
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the form "jmp addr_n" can be used as emulation triggers, where the value of 
addr_n differs for different emulation routines, to support emulation processing «n 
a manner similar to the approach discussed above (with a "break m» trigger 
leading to use of a lookup database, leading to execution of an emulation routine 
that corresponds to the "break m"). The transfers of control, faults, and/or related 
operations or events that are caused by an emulation patch may be referred to in 
general as emulation trigger events. For purposes of this disclosure, the term 
"flow control instruction" is used to refer to call instructions, jump instruct.ons, 
branch instructions, and any similar types of instructions. 

Figure 3 is a flowchart depicting various aspects of a process to support 
virilization with code patches according to an example embodiment of the 
present invention. The process depicted in Figure 3 begins with one or more 
guest VMs, such as guest VM 60, executing in processing system 20. At block 
180, guest VM 60 executes an instruction. As indicated at blocks 182 and 184 
and' the arrow returning to block 180, if the instruction did not cause a 
virilization fault and it was not a call to an emulation routine, guest VM 60 may 
retain control and may continue executing instructions. However, if the guest 
instruction was a flow control instruction transferring control to an existing 
emulation routine, the instruction may be considered an emulation patch or trigger. 
20 Processing system may handle that trigger as depicted at block 1 94 and 
described below. 

If the guest instruction did generate a fault, emulation manager 1 20 may 
then determine whether the guest instruction was an emulation patch or trigger, as 
indicated at block 192. For example, emulation manager 120 may determine that 

25 the instruction was an emulation trigger if the instruction was a break instruction 
that used one of the immediate values that were reserved for use in emulation 
patches, as described above. Alternatively, emulation manager 120 may 
determine whether the immediate value matches one of the values that have 
already been assigned to a particular emulation routine. Or, if cr.iim=0, emulation 

30 manager 1 20 may determine whether a combination of the guestJP and RID 
matches one of the values that have already been assigned to an emulation 
routine. 
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If the guest instruction was an emulation trigger, the process may pass to 
b,ock 194, where emulation manger 120 may handle the emulation trigger. For 
lnstan ce, emulation manager 120 may cause processing system 20 to execute the 
emulation routine that corresponds to the emu.ation trigger. That emulation 
routine may include any suitable set of instructions for emulating the orig.na, gues 
instruction. Upon completion of the emulation routine, VMM 40 may return control 
to VM 60 as indicated by the arrow returning to block 180 from block 194. For 
instance, as indicated above, the emulation routine may end with an rfi instruction. 
Alternatively, any other suitable technique may be used to return control to the 
auest VM If block 194 was reached in response to a virtualization fault, VMM 40 
may increment the guestJP before returning control to guest VM 60. If block 194 
was reached in response to a call to an emulation routine, VMM 40 may not need 
,o increment the gues.JP, because it may already have been incremented. 

,, emulation manager 1 20 determines at block 192 that the gues, instruction 
was not an emulation trigger, patch manager 1 10 may determine whether the 
guest instruction that caused the fault matches any of the instructions 130 for 
which code templates 132 are avertable, as indicated a, block 210. if the gues, 
instruction is no, found among instructions 130, VMM 40 may use any suitable 
methodology to emulate the instructions without patching, as indicated at block 
216 For instance, VMM 40 may use emulation code written in C to emulate the 
gu es, instruction, and VMM 40 may increment the guestJP before returning 
control to the VM. 

' However, referring again to block 21 0, if the guest instruction ,s found 
among instructions 1 30, patch manager 1 1 0 may conclude that the guest 
instruction is to be patched. As indicated a, block 220, patch manager 1 10 may 
then determine whether an emulation routine has already been built for the gues, 
instruction in question, for instance based on the routines already s,ored ,n 
emulation routine database 116. Patch manager 110 may tree, two gues, 
ins,ruc,ions as differen, instructions, such .hat each will have a different emulauon 
) routine, if those instructions differ in any pertinent attribute, as indicated above. !n 
particular, in some circumstances, the same emulation routine may be used for 
the same instruction in different slots, while other emulation routines may be used 
for only a single slot. As depicted a, blocks 222 and 224, if patch manager 110 
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has not already built an emulation routine for the present guest instruction, patch 
manager 110 may build a routine to emulate the guest instruction, and may store 
that routine in any suitable location(s) in any suitable data structure(s) (e.g., in 
emulation routine database 116). As described above, customization program 
1 1 4 may use a suitable code template from a collection of templates, such as 
those depicted in code template map 1 12, to generate the emulation routine. 

After generating an emulation routine or determining that a suitable 
emulation routine already exists, patch manager 1 10 may insert an emulation 
patch into the guest code, as depicted at block 226. For example, if customizat.on 
program 1 1 4 generated Routine A to provide for emulation of the guest .nstruct.on, 
and if Routine A was the first emulation routine to be generated, patch manager 
110 may insert an emulation patch such as "break BASEJD+0" into the guest 
code, in place of the original guest instruction. 

As indicated at block 230, VMM 40 may then return control to the guest VM 
without incrementing the instruction pointer, so that the guest VM will then execute 
the emulation trigger. In another embodiment, VMM 40 may determine whether 
the context is appropriate for executing the patch and, if it is, VMM 40 may 
execute the patch on behalf of the guest VM. As described above, when the 
emulation patch is executed, it may trigger a fault or other type of event that 
affects the flow of execution. VMM 40 may then handle the emulation trigger, as 
depicted at block 194 and described above. The process of Figure 3 may then 
return to block 180, and processing system 20 may resume execution of 
instructions from guest VM 60. 

In alternative embodiments, instead of or in addition to using dynamic 
patching a VMM may use static patching to replace guest instructions with 
emulation triggers. For instance, before loading an OS into a guest VM, the VMM 
may analyze the code image for the OS and may replace one or more of the 
original instructions with emulation triggers, based on a predetermined list of 
instructions to be patched. Many details of the patching operations may be the 
same or similar to the operations described above with regard to dynamic 
patching. 

In accordance with the above description, embodiments of the present 
invention may allow processing systems to provide instruction emulation for guest 
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VMS in a manner tha, is more efficient than conventional approaches For 
instance, according to the present disciosure, if may be unnecessary for the VMM 
t0 (a) retrieve the gues, instructions being emulated or .(b) save and restore a trap 

frame. , 
In light of the principles and example embodiments described and 
illustrated herein, it will be recognized that the described embodiments can be 
modified in arrangement and detail without departing from such principles. Also, 
although the foregoing discussion has focused on particular embodiments, other 
configurations are contemplated as well. Even though expressions such as ,n 
one embodiment," "in another embodiment,' or the like are used here.n, these 
phrases are meant to generally reference embodiment possibilities, and are not 
intended to limit the invention to particular embodiment configurations. As used 
herein, these terms may reference the same or different embodiments tha. are 
combinable into other embodiments. 

Similarly, although example processes have been described with regard to 
particular operations performed in a particular sequence, numerous modmcat.ons 
could be applied to those processes to derive numerous alternative embodiments 
of the present invention. For example, alternative embodiments may include 
processes that use fewer than all of the disclosed operations, processes that use 
additional operations, processes that use the same operations in a different 
sequence, and processes in which the individual operations disclosed here.n are 
combined, subdivided, or otherwise altered. 

Alternative embodiments of the invention also include machine access.ble 
media encoding instructions for performing the operations of the invention. Such 
embodiments may also be referred to as program products. Such machrne 
accessible media may include, without limitation, storage media Such as floppy 
disks hard disks, CD-ROMs, ROM, and RAM; as well as communications med.a 
such antennas, wires, optical fibers, microwaves, radio waves, and other 
electromagnetic or optical carriers. Accordingly, instructions and other data may 
be delivered over transmission environments or networks in the form of packets, 
serial data, parallel data, propagated signals, etc. and may be used ,n a 
distributed environment and stored locally and/or remotely for access by single or 
multi-processor machines. 

u 1 Q 
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I, should also be understood that the hardware and software components 
depioted herein represent functional elements that are reasonably self-conta,ned 
so that each can be designed, constructed, or updated substantially independently 
of the others In alternative embodiments, many of the components may be 
implemented as hardware, software, or combinations of hardware and software 
for providing the functionality described and illustrated herein. The hardware, 
software, or combinations of hardware and software for performing the operates 
of the invention may also be referred to as logic or control logic. 

In view of the wide variety of useful permutations that may be readrly 
derived from the example embodiments described herein, this detailed descript.on 
is intended to be illustrative only, and should not be taken as limiting the scope of 
, ne invention. What is claimed as the invention, therefore, is all implementations 
mat come within the scope and spirit of the following claims and all equivalents to 
such implementations. 
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what i.g r.laimed is: 

1 . A method for supporting virtual machines in a data processing system, the 

method comprising: 

executing an emulation patch for a guest virtual machine (VM) of a 
processing system, the emulation patch including data to facilitate identification of 
a routine for emulating a guest instruction; 

in response to execution of the emulation patch, transferring control from 
the guest VM to a virtual machine monitor (VMM) without saving a trap frame; and 

using the data from the emulation patch to find an emulation routine for the 
guest instruction. 

2 A method according to claim 1 , wherein the operation of executing an 
emulation patch comprises executing an instruction that includes an immediate 
value to be used for finding the emulation routine. 

3 A method according to claim 1 , wherein the operation of executing an 
emulation patch comprises executing a flow control instruction, wherein the flow 
control instruction includes an address to be used for finding the emulation rout.ne, 
the flow control instruction selected from a group consisting of: 

a call instruction; 

a jump instruction; and 

a branch instruction. 

4. A method according to claim 1 , wherein the operation of executing an 
emulation patch comprises executing an instruction selected from the group 

consisting of: 

a break instruction; 
a branch instruction; 
a call instruction; and 
a jump instruction. 
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5 A method according to claim 1 , further comprising: 

determining an index, based at least in part on data produced by the 

emulation patch; and 

using the index to find the emulation routine to be executed. 

6 A method according to claim 1 , further comprising: 

automatically determining whether the guest instruction is to be patched for 
emulation, based at least in part on a list of instructions to be patched; and 

inserting the emulation patch in response to a determination that the guest 
instruction is to be patched. 

7 A method according to claim 1 , further comprising: 

automatically determining whether the guest instruction is to be patched for 
emulation, based at least in part on a list of instructions to be patched; and 

retrieving a code template that corresponds to the guest instructs to be 
patched. 

8 A method according to claim 1 , further comprising: 

automatically determining whether the guest instruction is to be patched for 
emulation, based at least in part on a list of instructions to be patched; 

retrieving a code template that corresponds to the guest instruction to be 

patched; and 

generating the emulation routine for emulating the guest instruction, based 
at least in part on the code template. 

9. A method according to claim 1, further comprising: 

automatically determining whether the guest instruction is to be patched for 
emulation, based at least in part on a list of instructions to be patched, where.n 
the guest instruction resides in a slot of an instruction bundle; 
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retrieving a code template that corresponds to the. guest instruction to be 
patched; and 

generating the emulation routine for emulating the guest instruction, based 
at least in part on the code template and on the slot containing the guest 
instruction. 

1 0. A method according to claim 1 , further comprising: 

in response to execution of the emulation patch, find and executing the 
emulation routine for the guest instruction without decoding the guest instruction. 

11. A processing system to support virtual machines, the processing system 

comprising: 

a processor; 

a machine-accessible medium responsive to the processor; and 

instructions in the machine accessible medium, wherein the instructions, 
when executed by the processing system, cause the processing system to 
perform operations comprising: 

executing an emulation patch for a guest virtual machine (VM) of the 
processing system, the emulation patch including data to facilitate identification of 
a routine for emulating a guest instruction; 

in response to execution of the emulation patch, transferring control from 
the guest VM to a virtual machine monitor (VMM) without saving a trap frame; and 

using the data from the emulation patch to find an emulation routine for the 
guest instruction. 

12. A processing system according to claim 1 1 , wherein the emulation patch 
comprises an instruction with an immediate value, the immediate value to be used 
for finding the emulation routine. 

13. A processing system according to claim 1 1 , wherein the emulation patch 
comprises a flow control instruction with an address to be used for finding the . 
emulation routine, the flow control instruction selected from a group consisting of: 

a call instruction; 
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a jump instruction; and 
a branch instruction. 

1 4. A processing system according to claim 1 1 , wherein the emulation patch 
comprises an instruction selected from the group consisting of: 

a break instruction; 
a branch instruction; 
a call instruction; and 
a jump instruction. 

1 5. A processing system according to claim 1 1 , wherein the instructions 
perform operations comprising: 

determining an index, based at least in part on data produced by the 

emulation patch; and 

using the index to find the emulation routine to be executed. 

16. A processing system according to claim 1 1 , wherein the instructions 
perform operations comprising: 

automatically determining whether the guest instruction is to be patched, 
based at least in part on a list of instructions to be patched; and 

inserting the emulation patch in response to a determination that the guest 
instruction is to be patched. 

17. A processing system according to claim 1 1 , wherein the instructions 
perform operations comprising: • 

automatically determining whether the guest instruction is to be patched, 
based at least in part on a list of instructions to be patched; and 

retrieving a code template that corresponds to the guest instruction to be 
patched. 
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1 8. A processing system according to claim 1 1 , wherein the instructions 
perform operations comprising: 

automatically determining whether the guest instruction is to be patched, 
based at least in part on a list of instructions to be patched; 

retrieving a code template that corresponds to the guest instruction to be 
emulated; and 

generating the emulation routine for emulating the guest instruction, based 
at least in part on the code template. 

1 9. A processing system according to claim 1 1 , wherein the instructions cause 
the processing system to perform operations comprising: 

in response to execution of the emulation patch, finding and executing the 
emulation routine for the guest instruction without decoding the guest instruction. 

20. An apparatus to support virtual machines, the apparatus comprising: 
a machine accessible medium; and 

instructions in the machine accessible medium, wherein the instructions, 
when executed by a processing system, cause the processing system to perform 
operations comprising: 

executing an emulation patch for a guest virtual machine (VM) of the 
processing system, the emulation patch including data to facilitate identification of 
a routine for emulating a guest instruction; 

in response to execution of the emulation patch, transferring control from 
the guest VM to a virtual machine monitor (VMM) without saving a trap frame; and 

using the data to find an emulation routine for the guest instruction. 

21 . An apparatus according to claim 20, wherein the emulation patch 
comprises an instruction with an immediate value, the immediate value to be used 
for finding the emulation routine. 

22. An apparatus according to claim 20, wherein the emulation patch 
comprises a flow control instruction with an address to be used for finding the 
emulation routine, the flow control instruction selected from a group consisting of: 
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a call instruction; 

a jump instruction; and 

a branch instruction. 

5 23. An apparatus according to-claim 20, wherein the emulation patch 
comprises an instruction selected from the group consisting of: 

a break instruction; 

a branch instruction; 

a call instruction; 
10 a jump instruction. 

24. An apparatus according to claim 20, wherein the instructions perform 

operations comprising: 

determining an index, based at least in part on data produced by the 

15 emulation patch; and 

using the index to find the emulation routine to be executed. 

25. An apparatus according to claim 20, wherein the instructions perform 

operations comprising: 
20 automatically determining whether the guest instruction is to be patched, 

based at least in part on a list of instructions to be patched; and 

inserting the emulation patch in response to a determination that the guest 
instruction is to be patched. 

25 26. An apparatus according to claim 20, wherein the instructions perform 

operations comprising: 

automatically determining whether the guest instruction is to be patched, 
based at least in part on a list of instructions to be patched; 

retrieving a code template that corresponds to the guest instruction to be 

30 patched; and 

generating the emulation routine for emulating the guest instruction, based 

at least in part on the code template. 
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27. An apparatus according to claim 20, wherein the instructions, when 
executed, cause the processing system to perform operations comprising: 

in response to execution of the emulation patch, finding and executing the 
emulation routine for the guest instruction without decoding the guest instruction. 
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ABSTRACT 



A processing system executes an emulation patch for a guest virtual 
machine (VM) of the processing system. In one embodiment, the emulation patch 
includes data to facilitate identification of a routine to emulate a guest instruction. 
After executing the emulation patch for the guest VM, the processing system may 
use the data to find an emulation routine for emulating the guest instruction. The 
processing system may transfer control from the guest VM to a virtual machine 
monitor (VMM) in response to execution of the emulation patch, without saving a 
trap frame. The VMM may then find and execute the emulation routine for the 
guest instruction without decoding the guest instruction. A break instruction with 
an immediate value, for example, may be used for the emulation patch. The 
immediate value may be used for finding the emulation routine. Other 
embodiments are described and claimed. 
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